Release 10.1A: OpenEdge Development:
Progress Dynamics Administration

Advantages of the DCU

The following sections briefly outline the advantages of the DCU.

Developed in the Progress 4GL

The DCU is written in the Progress 4GL and runs using the Progress 4GL interpreter. This supports easy access to OpenEdge databases, especially the Repository, and makes upgrade programs easy to invoke.

Script-driven, customizable, and extensible

To enable you to create your own installs, the DCU is a framework in its own right. You can add more libraries to it, add or remove wizard pages, and change the display order of wizard pages. At the end of the wizard process, the data that is prompted for is available so that it can be used to drive the upgrade process.

Requires no database connection

Due to the complexity associated with installing a database, the DCU does not require any database connection to begin its functions. The DCU does connect to the databases you are upgrading or creating as required.

Does not require most managers

Just as it does not require any database connection, the DCU runs independently of framework managers such as the Session Manager, Profile Manager, or General Manager. The managers require database connections at run time to perform their tasks, so the DCU cannot rely on API calls to those managers.

Can be invoked from the command line

The DCU is invoked as the last part of the installation process. Since it runs outside the Progress Dynamics framework, you can invoke it from the command line.

Creates and updates databases

As part of setting up a new database or upgrading an existing one, the DCU applies schema changes to the database. The DCU applies these changes using the standard dictionary schema load program. When you create a new OpenEdge database, the DCU loads the initial data to populate the database from Progress dump files created from the central Repository.

Runs update programs

Data in one version of an application must be altered to match schema changes in a newer version of the application. These alterations are often performed through update programs. The DCU is designed to support the running of update programs.

Writes list of updates to Repository

When you use the DCU to apply updates to databases, the DCU writes details of the updates to the Repository. There are two reasons for this:

It provides the data required to continue the update process when you next connect to a Repository after running the DCU.
It allows you to determine what updates have been applied to a Repository and any application databases.

Invokes load of Progress Dynamics datasets automatically

Once all the necessary changes have been applied to a Repository, the DCU automatically loads the application data into the Repository. This data is deployed using datasets (ADOs). The DCU automates the process for loading ADOs to avoid user error. Since the deployment dataset API requires the Progress Dynamics framework, this process runs when you next log into the environment after running the DCU.

Invokes post-login updates automatically

Beyond the dataset load, you might have other update programs that must run within the Progress Dynamics environment so that schema triggers can fire and calls can be made to the managers. The DCU can automatically initiate update programs both before and after loading ADOs.

Can be run unattended in batch mode

If an end-user site you want to update is maintained with limited on-site technical support, you might prefer to have the DCU perform its updates in a completely unattended fashion. You can do this by configuring the DCU to run in batch mode.

Can retain site-specific data during Repository updates

You might need to update a site that contains site-specific or nonstandard application definitions. Depending on your application update, it might well unintentionally remove or modify these site-specific definitions in the process of updating other components of your application. Dynamics provides a set of utilities that you can run manually, or modify the DCU to run automatically, to save your site-specific data before the DCU performs its update, then to restore the site-specific data after the DCU update completes.